Engineering records are used to manage change and release processes for projects or tasks within an organization, for monitoring documentation of the revision process for product development, store change statuses, workflow functionality, etc. An engineering record can be viewed as a folder object that stores multiple data objects related to the life cycle of an engineering project change request. Engineering records include a header and a list of change items, which may include data objects for creating the engineering record, record type, change number, reason for change (e.g., customer request, internal request, cost reduction measure, or technical issue, etc.), target dates for completion of milestones, documents and notes relating to the project, routing list for user communications about the project, workflow logs, etc.
An engineering record consists of header attributes and a list of change items (e.g., materials and documents) that are subject to change. A process workflow of an engineering record determines which users or departments receive the engineering record for reviews and approvals. Engineering change request status management usually begins upon a triggering event or submission of a change request and continues until the project associated with the change request is complete. It is important for entities to be able to monitor these change and release processes, thus analytics capabilities are needed to identify success rates for the processes, identify any bottlenecks, and to determine how many engineering records exist and at what status, etc. Once the engineering record reaches the completed stage, the actual object changes may be executed.
One key feature of engineering records is that different engineering record types can be configured to reflect different kinds of change and release processes. Engineering records can be customized for a particular business, industry, or organization, and can be customized on different engineering record types to tailor customer-specific processes and to persist customer-specific attributes that are not part of any standard analytics reporting layer. The entities may each have their own customized database tables (or other data structures) and corresponding customer-specific attributes that will be used to store their engineering record data. In addition, a particular system may contain multiple different database tables for storing the engineering record header data.
Unfortunately, many of these customized database tables are not recognized by standard analytics applications, and thus it is a challenge to generate views of the engineering records data for consumption by such applications. Conventionally, customers must manually create database views for their customized database tables or they must model them inside a particular analytics tool using join conditions (e.g., using sequential query language (“SQL”) joins). This requires a lot of creation and maintenance effort as well as in-depth knowledge of databases and SQL.